Changing a time sensitive networking schedule implemented by a softswitch

ABSTRACT

Example methods, apparatus, systems and articles of manufacture (e.g., physical storage media) to change a time sensitive networking schedule implemented by a softswitch are disclosed. Example apparatus disclosed herein to change a time sensitive networking schedule implemented by a first softswitch on a compute node include a network node configurator to deploy a second softswitch on the compute node based on a first configuration specification associated with the first softswitch, configure the second softswitch to implement an updated time sensitive networking schedule different from the time sensitive networking schedule implemented by the first softswitch, and replace the first softswitch with the second softswitch in response to a determination that a first set of constraints is met for simulated network traffic processed by the second softswitch based on the updated time sensitive networking schedule. Disclosed example apparatus also include a simulator to apply the simulated network traffic to the second softswitch.

RELATED APPLICATION(S)

This patent arises from a continuation of U.S. patent application Ser.No. 16/586,391 (now U.S. Pat. No. ______), which is titled “CHANGING ATIME SENSITIVE NETWORKING SCHEDULE IMPLEMENTED BY A SOFTSWITCH,” andwhich was filed on Sep. 27, 2019. Priority to U.S. patent applicationSer. No. 16/586,391 is claimed. U.S. patent application Ser. No.16/586,391 is hereby incorporated herein by reference in its entirety.

FIELD OF THE DISCLOSURE

This disclosure relates generally to time sensitive networking and, moreparticularly, to changing a time sensitive networking scheduleimplemented by a softswitch.

BACKGROUND

Time sensitive networks include network devices (also referred to hereinas network elements) that interoperate to provide, among other things,time synchronization and packet scheduling to, for example, ensure oneor more latency targets for packets sent from one network device toanother network device are met. For example, industrial controlapplications may rely on such network latency target(s) being met toachieve proper operation of the industrial equipment being controlled.Time sensitive networks utilize a time sensitive networking schedulethat is created based on the actual topology of the network andapplication latency requirements. The time sensitive networking scheduleis implemented by the network devices. When the network topology changesand/or new applications are deployed in the time sensitive network, anupdated time sensitive networking schedule is created and provided tothe network devices for implementation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example environment of use including anexample central configuration controller and an example network nodeconfigurator to change a time sensitive networking schedule implementedby an example softswitch of a compute node in accordance with teachingsof this disclosure.

FIGS. 2-5 illustrate an example procedure performed by the examplenetwork node configurator of the example compute node of FIG. 1 tochange the time sensitive networking schedule implemented by thesoftswitch of the compute node in accordance with teachings of thisdisclosure.

FIG. 6 illustrates an example virtualized industrial function descriptorprocessed by the central configuration controller of FIG. 1.

FIG. 7 is a block diagram of an example implementation of the networknode configurator of FIGS. 1-5.

FIG. 8 is a flowchart representative of example computer readableinstructions that may be executed to implement the example centralconfiguration controller of FIG. 1.

FIGS. 9-12 are flowcharts and pseudocode representative of examplecomputer readable instructions that may be executed to implement theexample network node configurator of FIGS. 1-5 and/or 7.

FIGS. 13-14 collectively illustrated a flowchart representative ofexample computer readable instructions that may be executed to implementthe example central configuration controller of FIG. 1 and the examplenetwork node configurator of FIGS. 1-5 and/or 7.

FIG. 15 is a block diagram of an example processor platform structuredto execute the example computer readable instructions of FIGS. 8, 13and/or 14 to implement the example central configuration controller ofFIG. 1.

FIG. 16 is a block diagram of an example processor platform structuredto execute the example computer readable instructions of FIGS. 9, 10,11, 12, 13 and/or 14 to implement the example network node configuratorof FIGS. 1-5 and/or 7.

The figures are not to scale. In general, the same reference numberswill be used throughout the drawing(s) and accompanying writtendescription to refer to the same or like parts, elements, etc.Connection references (e.g., attached, coupled, connected, and joined)are to be construed broadly and may include intermediate members betweena collection of elements and relative movement between elements unlessotherwise indicated. As such, connection references do not necessarilyinfer that two elements are directly connected and in fixed relation toeach other.

Descriptors “first,” “second,” “third,” etc. are used herein whenidentifying multiple elements or components which may be referred toseparately. Unless otherwise specified or understood based on theircontext of use, such descriptors are not intended to impute any meaningof priority, physical order or arrangement in a list, or ordering intime but are merely used as labels for referring to multiple elements orcomponents separately for ease of understanding the disclosed examples.In some examples, the descriptor “first” may be used to refer to anelement in the detailed description, while the same element may bereferred to in a claim with a different descriptor such as “second” or“third.” In such instances, it should be understood that suchdescriptors are used merely for ease of referencing multiple elements orcomponents.

DETAILED DESCRIPTION

Example methods, apparatus, systems and articles of manufacture (e.g.,physical storage media) to change a time sensitive networking scheduleimplemented by a softswitch are disclosed herein. Example apparatusdisclosed herein to change a time sensitive networking scheduleimplemented by a first softswitch on a compute node include an examplenetwork node configurator to deploy a second softswitch on the computenode based on a first configuration specification associated with thefirst softswitch. The example network node configurator is also toconfigure the second softswitch to implement an updated time sensitivenetworking schedule different from the time sensitive networkingschedule implemented by the first softswitch. The example network nodeconfigurator is further to replace the first softswitch with the secondsoftswitch in response to a determination that a first set ofconstraints is met for simulated network traffic processed by the secondsoftswitch based on the updated time sensitive networking schedule. Suchdisclosed example apparatus also include an example traffic simulator toapply the simulated network traffic to the second softswitch.

In some disclosed examples, the first softswitch is to communicate withrespective first ports (also referred to herein as port connections) ofcorresponding ones of a first set of virtual machines on the computenode to provide the first set of virtual machines with access to anetwork that implements time sensitive networking. In some suchdisclosed examples, to replace the first softswitch with the secondsoftswitch, the network node configurator is to: (i) connect the secondsoftswitch to a network interface of the compute node, (ii) addrespective second ports to corresponding ones of the first set ofvirtual machines, (iii) bind the respective second ports of thecorresponding ones of the first set of virtual machines to the secondsoftswitch, (iv) delete the respective first ports of the correspondingones of the first set of virtual machines, and (v) delete the firstsoftswitch from the compute node.

In some disclosed examples, the updated time sensitive networkingschedule is to support deployment of a new virtual machine, which hostsa latency sensitive workload, to the compute node. In some suchdisclosed examples, the network node configurator is to: (i) connect aport of the new virtual machine to the second softswitch, (ii) configurethe workload to operate in a test mode, (iii) monitor metrics associatedwith the simulated network traffic processed by the second softswitch,and (iv) configure the workload to operate in an operational mode afterthe determination that the first set of constraints is met for thesimulated network traffic processed by the second softswitch based onthe updated time sensitive networking schedule. In some such disclosedexamples, the simulated network traffic includes first simulated networktraffic associated with a first set of virtual machines on the computenode and second simulated network traffic associated with the newvirtual machine. For example, the first set of virtual machines may bein communication with the first softswitch, and the first simulatedtraffic may correspond to previously monitored network traffic obtainedduring operation of the first set of virtual machines.

In some disclosed examples, the network node configurator is to deletethe second softswitch and the updated time sensitive networking schedulefrom the compute node in response to a determination that the first setof constraints is not met for the simulated network traffic processed bythe second softswitch based on the updated time sensitive networkingschedule.

In some disclosed examples, the second softswitch is associated with asecond configuration specification, which is to correspond with thefirst configuration specification when the second softswitch isinitially deployed on the compute node. In some such examples, inresponse to the determination that the first set of constraints is metfor the simulated network traffic, the network node configurator is toadjust the second configuration of the second softswitch to satisfy atleast one of a second set of constraints to be met for the simulatednetwork traffic processed by the second softswitch based on the updatedtime sensitive networking schedule. For example, the network nodeconfigurator may iteratively adjust the second configuration of thesecond softswitch to satisfy other ones of the second set of constraintsto be met for the simulated network traffic until a time limit isreached.

Other example apparatus disclosed herein to change a time sensitivenetworking schedule implemented by a softswitch on a compute nodeinclude an example central user configurator to parse a virtualizedindustrial function descriptor corresponding to a virtualized workloadto determine a set of parameters for an updated time sensitivenetworking schedule to be implemented by the softswitch. Such disclosedexample apparatus also include an example central network configuratorto determine the updated time sensitive networking schedule based on theset of parameters, and send the updated time sensitive networkingschedule to the compute node.

Some such disclosed example apparatus also include an exampleorchestrator to parse the virtualized industrial function descriptor todetermine a virtual machine configuration specification for a virtualmachine to deploy on the compute node to host the virtualized workload.In some examples, the orchestrator is to send the virtual machineconfiguration specification to the compute node to cause the virtualmachine to be deployed on the compute node. In some examples, theorchestrator is further to delete the virtual machine from the computenode in response to a message from the compute node indicating a firstset of constraints is not met by the updated time sensitive networkingschedule.

In some disclosed examples, the central user configurator is to deletethe updated time sensitive networking schedule in response to a messagefrom the compute node indicating a first set of constraints is not metby the updated time sensitive networking schedule.

In some disclosed examples, the central user configurator is todetermine whether the central network configurator supports generationof the updated time sensitive networking schedule based on a first oneof the set of parameters. In some such examples, the central userconfigurator is to discard the first one of the set of parameters, orreplace the first one of the set of parameters with a differentparameter, when the central network configurator does not supportgeneration of the updated time sensitive networking schedule based onthe first one of the set of parameters.

These and other example methods, apparatus, systems and articles ofmanufacture (e.g., physical storage media) to change a time sensitivenetworking schedule implemented by a softswitch are disclosed in furtherdetail below.

As mentioned above, time sensitive networks include network elementsthat interoperate to provide, among other things, time synchronizationand scheduling to, for example, ensure one or more latency targets forpackets sent from one network element to another network element aremet. For example, network elements that implement a time sensitivenetwork may be structured to implement a time sensitive networking (TSN)schedule in accordance with a defined standard, such as the Institute ofElectrical and Electronics Engineers (IEEE) 802.1Qbv Standard, publishedon Mar. 18, 2016. The TSN schedule specified by the IEEE 802.1QbvStandard utilizes a gate structure and corresponding packetclassifications to support strictly timed packet transmission slots.Interest in time sensitive networks is increasing due to their abilityto ensure packet latency targets are met on an open standards-basednetwork (as compared to a proprietary network). For example, industrialcontrol applications may rely on deterministic packet latencydistributions with a known upper latency bound (e.g., such as 31.25microseconds, or some other bound) for the isochronous, real-timenetwork traffic generated by a given control function, such as aprogrammable logic controller (PLC), a motion controller, a numericalcontroller, etc.

There is also interest in the use of softswitches to implement networkelements that provide access to an underlying network. For example, theuse of softswitches in cloud computing environments is becoming thenorm. A softswitch can be a virtual switch that is implemented by one ormore virtual network functions (VNFs) that execute on a compute node,such as a server, a router, a cloud host, etc. As such, the termssoftswitch, virtual switch, vSwitch, etc., are synonymous and can beused interchangeably unless noted otherwise For example, interest in theuse of softswitches in industrial applications is being driven, at leastin part, by customer interest in the use of virtualized industrialfunctions (VIFs) to implement the workloads to control industrialequipment, and in the horizontal consolidation of the VIFs on edgecompute nodes located at or near the sites where the equipment is to becontrolled. Softswitches can be used in such examples to provide networkconnectivity between the VIF workloads on a compute node and theexternal equipment being controlled. Softswitches can also providenetwork connectivity between the VIF workloads on the compute nodeitself.

Thus, in addition to implementing softswitches that support the flexibleworkload deployments and removal operations associated with such networkfunction virtualization (NFV) environments, there is a need forsoftswitches that can support TSN. However, existing softswitches maynot be able to support TSN, especially for applications, such asindustrial control applications, with strict latency targets. Forexample, in an IEEE 802.1Qbv implementation, the TSN schedule for agiven time sensitive network is determined based on the actual topologyof the network. When a new VIF workload, with its associateddeterministic and real-time packet cycle times, is to be deployed on acustomer's edge compute node (or cluster), an updated TSN schedule iscreated to accommodate that new VIF workload in the network. The updatedTSN schedule is deployed to the TSN network endpoints. The TSN networkendpoints include the TSN-enabled softswitch executing on that computenode to provide first-hop connectivity to the new VIF workload. Existingsoftswitch implementations may require stopping the softswitch, applyingthe updated TSN schedule to the softswitch, and thenre-initializing/restarting the softswitch to have the updated TSNschedule take effect at the softswitch.

However, the sequence of stopping the softswitch, applying the updatedTSN schedule to the softswitch, and then re-initializing/restarting thesoftswitch may cause existing workloads connected to the softswitch toexperience packet communication delays and/or dropouts that exceed thelatency target (e.g., 31.25 microseconds, or some other target) of thetime sensitive network. To address this technical problem, exampletechnical solutions disclosed herein utilize a duplicate softswitch(also referred to herein as a digital twin softswitch) to enable dynamicchanging of a TSN schedule implemented by a softswitch without impactingthe deterministic and real-time packet communications associated withexisting workloads connected to the softswitch. For example, a change ofthe TSN schedule may be caused by a new workload being deployed in thetime sensitive network. As discussed in further detail below, exampletechnical solutions disclosed herein also utilize the duplicatesoftswitch (digital twin softswitch) to validate an updated TSN schedulein situ with the new workload being deployed, and can prevent deploymentof the updated TSN schedule if a performance issue is detected.

Turning to the figures, a block diagram of an example centralconfiguration controller 102 and an example network node configurator138 structured to change a time sensitive networking scheduleimplemented by an example softswitch 106 of a compute node 104 inaccordance with teachings of this disclosure is illustrated in FIG. 1 inthe context of an example environment of use 100. In the illustratedexample, the compute node 104 corresponds to an edge compute node 104deployed in an industrial environment (e.g., facility, plant, etc.) toexecute workloads 108, 110, 112 to control example physical equipment114 in the industrial environment. For example, the physical equipmentcan include a distributed control system (DCS), a physical programmablelogic controller (PLC), a gateway, a robot, a tool, vision processingequipment, etc. As such, the compute node 104 can be implemented by, forexample, any appropriate computing device or combination of computingdevices, such as a server in an edge cluster, an industrial computer,etc. In some example, the compute node 104 is implemented by a processorplatform such as the example processor platform 1600 of FIG. 16, whichis described in further detail below. Although the compute node 104 ofthe illustrated example is deployed in an industrial environment, in theother examples, the compute node 104 can be deployed in other types ofenvironments. For example, the compute node 104 could correspond to acontroller to execute workloads to control fifth generation (5G) smallcell sites, cloud center server farms, etc.

In the example environment 100 of FIG. 1, the compute node 104communicates with the physical equipment 114 via an example timesensitive network 116. In the illustrated example, the time sensitivenetwork 116 connects the compute node 104 with the physical equipment114 and, in some examples, other example compute node(s) 118 via anexample bridge 120. The bridge 120 can be implemented by any networkbridge, router, server, device, etc., capable of implementing a TSNschedule (e.g., a TSN schedule in accordance with the IEEE 802.1QbvStandard). Each of the compute node(s) 118 of the illustrated examplecan be implemented by any appropriate computing device or combination ofcomputing devices, such as a server in an edge cluster, an industrialcomputer, etc., which may be similar to, or different from, thecomputing node 104.

To connect to the time sensitive network 116, the compute node 104include an example network interface card (MC) 122. Likewise, thecompute node(s) 118 include respective NICs 124. The NICs 122 and 124can be implemented by any network interface circuitry capable ofconnecting to the time sensitive network 116. For example, if the timesensitive network 116 is a wired network, such as an Ethernet network, adigital subscriber line (DSL) network, etc., the NICs 122 and 124 can beimplemented by appropriate, corresponding wired network interfacecircuitry. If the time sensitive network 116 is a wireless network, suchas a wireless local area network (WLAN), a cellular network, etc., theNICs 122 and 124 can be implemented by appropriate, correspondingwireless network interface circuitry. In the illustrated example of FIG.1, the softswitch 106 implemented on the compute node 104 communicateswith the NIC 122 of the compute node 104 via an example data planedevelopment kit (DPDK) 126. The DPDK provides a set of libraries toenable efficient communication of data packets between the softswitch106 and the NIC 122.

The softswitch 106 of the compute node 104 corresponds to a virtualswitch implemented by one or more virtual network functions (VNFs) toprovide the workloads 108, 110, 112 executing on the compute node 104with access to the time sensitive network 116, which connects theworkloads 108, 110, 112 to the physical equipment 114. In some examples,the softswitch 106 also implements an example internal network 127 toallow some or all of the workloads 108, 110, 112 to communicate witheach other within the compute node 104. The workloads 108, 110, 112 cancorrespond to any appropriate workload to control the physical equipment114, monitor the physical equipment 114, process data returned by thephysical equipment 114 for use in other applications, etc. For example,the workloads 108 and 110 correspond to respective example virtual PLCs108 and 110 executed to control respective physical equipment 114 (e.g.,such as respective robots, tools, etc.) in a deterministic and real-timemanner. The workload 112 of the illustrated example corresponds to avision processing workload 112, which is a non-deterministic workload toperform computer vision processing on data returned from one or more ofthe physical equipment 114. Thus, the softswitch 106 can supportdeterministic and non-deterministic workloads. In the illustratedexample of FIG. 1, the workloads 108, 110, 112 are hosted by respectivevirtual machines (VMs) and/or containers that interface with thesoftswitch 106. For example, the workloads 108 and 110 are hosted byrespective example VMs 128 and 130, whereas the workload 112 is hostedby an example container 132. As shown in the example of FIG. 1, the VMs128 and 130 also include respective example virtual NICs (VNICs) 134 and136 to connect the VMs 128 and 130 with the softswitch 106.

The softswitch 106 of the illustrated example implements a TSN schedule,such as a TSN schedule compliant with the IEEE 802.1Qbv Standard, totransmit and receive data packets as part of the time sensitive network116. For example, the softswitch 106 may include multiple data buffers(e.g., queues) assigned to different data classes defined by the TSNschedule, which the softswitch 106 gates on and off to provide access tothe time sensitive network 116 to meet timing requirements specified bythe TSN schedule. To configure the softswitch 106 to implement a TSNschedule deployed to the compute node 104, the compute node 104 includesthe example network node configurator 138. The other compute node(s) 118also include respective example network node configurator(s) 139. Asdisclosed in further detail below, the network node configurator 138 isalso responsible for changing the TSN schedule implemented by thesoftswitch 106 when an updated TSN schedule is deployed to the computenode 104. The network node configurator 138 is also responsible forvalidating the updated TSN schedule before deploying the updated TSNschedule for softswitch implementation. For example, an updated TSNschedule may be deployed to the compute node 104 when a new workload,such as an example workload 140, is to be deployed to the compute node104 for execution. As shown in FIG. 1, the workload 140 may be similarto, or different from, the workloads 108, 110, 112, and may be hosted byan example VM 142 with an example VNIC 144. As described in furtherdetail below, the updated TSN schedule is created to accommodate thepacket communication timing requirements of the new workload 140 to bedeployed on the compute node 104, as well as the packet communicationtiming requirements of existing workloads operating in the timesensitive network 116, such as the workloads 108, 110 and 112. As alsodescribed in further detail below, the network node configurator 138utilizes one or more example data repositories 146 to configure thesoftswitch 106 to implement a TSN schedule, to change the TSN scheduleimplemented by the softswitch 106, to confirm that an updated TSNschedule is viable before deploying the updated TSN schedule forsoftswitch implementation, etc. The data repositories 146 can beimplemented by any number and/or type(s) of storage devices, memories,etc. For example, the data repositories 146 can be implemented by theexample volatile memory 1614 and/or the example mass storage device(s)1628 of FIG. 16, which are described in further detail below.

The central configuration controller 102 is included in the exampleenvironment 100 to deploy workloads and TSN schedules to the computenodes 104 and 118 in communication with the time sensitive network 116.As such, the central configuration controller 102 communicates with thecompute nodes 104 and 118 via an example network 148. The network 148can be implemented by any number and/or type(s) of communicationnetworks. For example, the communication network 125 can be implementedby one or more wired/cabled networks, one or more wireless networks(e.g., mobile cellular networks, satellite networks, etc.), one or moreproprietary networks, one or more public networks (e.g., such as theInternet), etc., or any combination thereof. In the illustrated example,the network 148 is different from the time sensitive network 116 thatconnects the compute nodes 104 and 118 with the physical equipment 114.

The central configuration controller 102 can be implemented by, forexample, any appropriate computing device or combination of computingdevices. In some example, the central configuration controller 102 isimplemented by a processor platform such as the example processorplatform 1500 of FIG. 15, which is described in further detail below. Inthe illustrated example of FIG. 1, the central configuration controller102 includes an example orchestrator 150 to deploy workloads to thecompute nodes 104 and 118. The central configuration controller 102 ofthe illustrated example also includes an example central userconfigurator 152 and an example central network configurator 154 toconfigure the time sensitive network 116. For example, the centralnetwork configurator 154 includes an example scheduler 156 to create TSNschedules to be deployed to the network nodes 104 and 118 to implementthe time sensitive network 116. As described in further detail below,the workloads and TSN schedules are created based on example virtualizedindustrial function descriptors (VIFD) 158 that specify theinstantiation parameters, operational behaviors, network communicationrequirements, etc., for the workloads to be deployed to the computenodes 104 and 118. An example procedure performed by the centralconfiguration controller 102 and the network node configurator 138 tochange a TSN schedule implemented by the softswitch 106 of the computenode 104 is described in further detail below in connection with FIGS.1-5. An example VIFD 158 is illustrated in FIG. 6, which is alsodescribed in further detail below.

With reference to FIG. 1, an example procedure performed by the centralconfiguration controller 102 and the network node configurator 138 tochange a TSN schedule implemented by the softswitch 106 of the computenode 104 begins with the central configuration controller 102 receivingthe VIFD 158 for the new workload 140 to be deployed to the compute node104. As noted above, the VIFD 158 specifies the instantiationparameters, operational behaviors, network communication requirements,etc., for the new workload 140. In some examples, the VIFD 158 is anenhancement of the virtual network function descriptor (VNFD) specifiedby the European Telecommunications Standards Institute (ETSI) in thespecification “Network Functions Virtualisation (NFV) Release 2;Protocols and Data Models; NFV descriptors based on TOSCAspecification,” version 2.5.1, published in December 2018. In some suchexamples, the VIFD 158 is a file that uses the Topology andOrchestration Specification for Cloud Applications (TOSCA) language tospecify the instantiation parameters, operational behaviors, networkcommunication requirements, etc., for the new workload 140. For example,a VNFD uses the TOSCA language to specify the instantiation parametersand operational behaviors of VNF workloads. For example, the VNFD cancontain key performance indicators (KPIs) and/or other requirements thatcan be used in the process of onboarding and managing the lifecycle ofthe VNF workloads. However, a VNFD does not describe the real-timenetworking requirements for a workload, such as packet communicationjitter targets/bounds, latency targets/bounds, etc. The VIFD 158 extendsthe VNFD to include network communication scheduling requirements forthe workload 140, such as frame spacing, mean latency, an upper boundfor latency, etc.

An example implementation of the VIFD 158 is illustrated in FIG. 6. Theexample VIFD 158 of FIG. 6 includes an example topology definitionsection 605, which specifies the instantiation parameters andoperational behaviors of the workload 140. The example VIFD 158 of FIG.6 also includes an example scheduling constraints definition section610, which specifies the network communication scheduling requirementsfor the workload 140.

Returning to FIG. 1, in the illustrated example, the orchestrator 150and the central user configurator 152 read the VIFD 158 for the workload140. The orchestrator 150 parses the VM-related fields of the VIFD 158to define the resource requirements (e.g. number of virtual centralprocessing units (CPUs), memory, storage, network interfaces, etc.) forthe workload 140 to be deployed (e.g., in real-time) to the compute node104 (e.g., which may be an edge compute node or cluster in an industrialcomputer premises system). For example, the orchestrator 150 parses thetopology definition section 605 of the VIFD 158 to determine theparameters (e.g., VM flavor, number of network connections, image name,number of cores, core isolation, core pinning, memory/disk sizes, etc.)to be used by the orchestrator to create a VM configurationspecification for the VM 142, which is to host the workload 140 on thecompute node 104. The orchestrator 150 then creates the VM configurationspecification for the VM 142 based on the parameters parsed from theVIFD 158, and sends (e.g., transmits) the VM configuration specification(e.g., via the network 148) to the compute node 104 to deploy the VM 142and workload 140 to the compute node 104. Accordingly, the orchestrator150 is an example of means for parsing a virtualized industrial functiondescriptor to determine a virtual machine configuration specificationfor a virtual machine to deploy on a compute node to implement avirtualized workload.

In the illustrated example, the central user configurator 152 parses thescheduling-related fields of the VIFD 158 to determine the networkcommunication scheduling requirements for the workload 140. For example,the central user configurator 152 parses the scheduling constraintsdefinition section 610 of the VIFD 158 to identify the networkcommunication scheduling parameters specified for the workload 140,which will be used by the central network configurator 154 to create anupdated TSN schedule to accommodate the workload 140 in the timesensitive network 116. In some examples, the central user configurator152 is implemented to meet the functional requirements of a central userconfigurator in accordance with the IEEE 802.1Qcc Standard, published onOct. 31, 2018. In some such examples, the central user configurator 152is an architectural component of a TSN environment, and is responsiblefor the discovery of end stations, retrieving end station capabilitiesand user requirements, etc. In the illustrated example of FIG. 1, thecentral user configurator 152 is responsible for identifying the networkcommunication scheduling parameters specified in the VIFD 158 for theworkload 140, and for transposing the identified network communicationscheduling parameters into a parameter set supported by the centralnetwork configurator 154. In some examples, the central userconfigurator 152 determines whether the network communication schedulingparameters identified in the VIFD 158 for the workload 140 are supportedby the central network configurator 154. In some such examples, if anidentified network communication scheduling parameter is not supportedby the central network configurator 154, the central user configurator152 replaces the unsupported parameter with a different parameter (e.g.,a nearest approximation) supported by the central network configurator154. In some examples, if an identified network communication schedulingparameter is not supported by the central network configurator 154, thecentral user configurator 152 discards the unsupported parameter (e.g.,if a suitable substitute is not available). Accordingly, the centraluser configurator 152 is an example of means for parsing a virtualizedindustrial function descriptor corresponding to a virtualized workloadto determine a set of parameters for an updated time sensitivenetworking schedule to be implemented by one or more softswitches. Forexample, the central user configurator 152 may provide an updated timesensitive networking schedule to one softswitch to address communicationrequirements among workloads on the compute node associated with thatsoftswitch. In other examples, the central user configurator 152 mayprovide an updated time sensitive networking schedule to multiplesoftswitches to address communication requirements across the timesensitive network 116 among workloads on different compute nodesassociated with the different softswitches.

In the illustrated example, the central network configurator 154provides a centralized means for performing resource reservation,scheduling, configuration of the compute nodes 104, 118 and the timesensitive network 116, etc. In some examples, the central networkconfigurator 154 communicates with the compute nodes 104, 118, andpossibly other elements of the time sensitive network 116 (e.g., thebridge 120, etc.), via a remote management protocol, such as the networkconfiguration protocol (NETCONF), RESTCONF, etc. In the illustratedexamples, the central network configurator 154 includes the scheduler156 to create an updated TSN schedule based on the set of schedulingparameters provided by the central user configurator 152 (e.g., afterany replacing/discarding, as described above) to accommodate the newworkload 140. For example, the scheduler 156 of the central networkconfigurator 154 creates the updated TSN schedule that complies withIEEE 802.1Qbv Standard and is intended to meet the real-time,isochronous packet transmission requirements specified in the VIFD 158for the workload 140. Accordingly, the central network configurator 154is an example of means for determine an updated TSN schedule based on aset of parameters specified for a virtualized workload.

In the illustrated example, when the updated TSN schedule is ready, itis sent to the network node configurator 138 of the compute node 104 fordeployment to the softswitch 106. For example, the updated TSN schedulemay be sent via an end station configuration protocol, which may bebased on a publish/subscribe mechanism, such as the OPC unifiedarchitecture (OPC-UA) protocol. Turning to FIG. 2, in response toreceiving the updated TSN schedule, the network node configurator 138creates (e.g., instantiates) an example duplicate softswitch 205, whichis a duplicate or digital twin of the existing softswitch 205. Thenetwork node configurator 138 uses the duplicate softswitch 205 to testthe updated TSN schedule and, upon successful validation, to apply thenew TSN schedule at the compute node 104 without interruption of theexisting workload 108, 110, 112 connected to the softswitch 106.Accordingly, the network node configurator 138 is an example of meansfor replacing a first softswitch implementing a first (e.g., existing)TSN schedule at a compute node with a second softswitch to implement asecond (e.g., updated) TSN schedule at the compute node, which caninclude deploying the second softswitch on the compute node with aninitial configuration based on (e.g., matching) the configuration of thefirst softswitch, configuring the second softswitch to implement thesecond (e.g., updated) TSN schedule, and replacing the first softswitchwith the second softswitch after validation of the second TSN scheduleimplemented by the second softswitch.

For example, in response to receiving the updated TSN schedule, thenetwork node configurator 138 accesses a configuration specification forthe softswitch 106 from a softswitch specification repository includedin the repositories 146 and/or downloaded from the central configurationcontroller 102. The configuration specification for the softswitch 106may specify the configuration(s) of the VNF(s) and VM(s) implementingthe softswitch 106, and/or any other configuration settings/data thatdefine the implementation of the softswitch 106. In some examples, thenetwork node configurator 138 also accesses any real-time metrics,status, etc., from the softswitch 106. The network node configurator 138uses the accessed configuration specification for the softswitch 106,and any other metrics, status, etc., to create/instantiate the duplicatesoftswitch 205 on the compute node 104 such that the duplicatesoftswitch 205 is a digital copy (or digital twin) of the softswitch106.

In some examples, the network node configurator 138 uses theconfiguration specification for the softswitch 106 to create/instantiatethe duplicate softswitch 205 on the compute node 104 such that theduplicate softswitch 205 is an exact duplicate (e.g., a digital twin) ofthe softswitch 106. In other examples, the network node configurator 138uses the configuration specification for the softswitch 106 tocreate/instantiate the duplicate softswitch 205 on the compute node 104such that the duplicate softswitch 205 is substantially similar to thesoftswitch 106, except for some inconsequential differences in theconfiguration parameters. For example, the configuration specificationfor the softswitch 106 may specify configuration parameters defining thecomposition of the softswitch 106, such as a number of processing cores,an amount of memory, total number of data buffers (e.g., queues) fortransmitting and receiving data packets, distribution of the databuffers (e.g., queues) across different data traffic classes (e.g., interms of the number of data buffers assigned to each different dataclass), number of port connections assignable to VMs, etc. In examplesin which the duplicate softswitch 205 is an exact duplicate (e.g., adigital twin) of the softswitch 106, the network node configurator 138may create/instantiate the duplicate softswitch 205 such that itsconfiguration specification includes all of the same configurationparameters as the configuration specification of the softswitch 106. Inexamples in which the duplicate softswitch 205 is a substantiallysimilar copy of the softswitch 106, the network node configurator 138may create/instantiate the duplicate softswitch 205 such that itsconfiguration specification includes some of the same configurationparameters as the configuration specification of the softswitch 106(e.g., such as the same number of processing cores, the same totalnumber of data buffers (e.g., queues) for transmitting and receivingdata packets, the same distribution of the data buffers (e.g., queues)across different data traffic classes, etc.), but other configurationparameters may differ (e.g., amount of memory, number of portconnections assignable to VMs, etc.) if the parameters that differ willresult in little to no change in operational performance between thesoftswitch 106 and the initially deployed duplicate softswitch 205.

In the illustrated example of FIG. 2, the network node configurator 138also connects the VNIC 144 of the VM 142, which has been deployed to thecompute node 104 to implement the virtualized workload 140, to theduplicate softswitch 205. For example, the network node configurator 138may access a VM configuration file for the VM 142 from a VMconfiguration repository included in the repositories 146, access aconfiguration specification for the duplicate softswitch 205 (whichinitially corresponds/matches the configuration specification forsoftswitch 106) from the softswitch specification repository included inthe repositories 146, and update the configuration files to map a portof VNIC 144 of the VM 142 to a port of the softswitch 205. In theillustrated example, the network node configurator 138 also configuresthe workload 140 hosted by the VM 142 to operate in a test mode (e.g.,by setting an appropriate configuration setting, value, field, etc.).

Turning to FIG. 3, after the duplicate softswitch 205 is instantiated onthe compute node 104 and connected to the VM 142, which is hosting theworkload 140 operating in test mode, the network node configurator 138deploys the updated TSN schedule to the softswitch 205 and tests theupdated TSN schedule using simulated network traffic. For example, thenetwork node configurator 138 includes an example traffic simulator 305,which implements an on-node simulation engine on the compute node 104that generates simulated network traffic to validate the updated TSNschedule implemented by the duplicate softswitch 205 before thevalidated updated TSN schedule is deployed for operation. Although thetraffic simulator 305 is illustrated as being implemented by the networknode configurator 138 in the illustrated example, in other examples, thetraffic simulator 305 could be a separate element implemented on thecompute node 104. Accordingly, the traffic simulator 305 is an examplemeans for applying simulated network traffic to a softswitch.

In some examples, the traffic simulator 305 generates the simulatednetwork traffic from actual network traffic monitored by the trafficsimulator 305 during operation of the softswitch 106. For example, thetraffic simulator 305 can monitor the actual network trafficcommunicated to/from the elements connected to the softswitch 106, suchas the VMs 128/130 and the container 132, during operation of theworkloads 108, 110, 112. In some examples, the traffic simulator 305stores the monitored network traffic in a simulated network trafficrepository included in the repositories 146. For example, the trafficsimulator 305 can store the monitored network traffic as one or morepacket-capture (PCAP) files in the simulated network traffic repositoryincluded in the repositories 146. In some examples, the trafficsimulator 305 also obtains a test traffic file, such as a test trafficPCAP file, associated with new workload 140 being deployed to thecompute node 104. For example, the orchestrator 150 may transmit a testtraffic file to the compute node 104 (e.g., to the network nodeconfigurator 138 and/or the traffic simulator 305) with the VMconfiguration specification for the VM 142 implementing the new workload140, which is stored in the simulated network traffic repositoryincluded in the repositories 146. The test traffic file in such examplesmay be generated to mimic the network traffic to be transmitted toand/or received from the type of physical equipment expected to be incommunication with the workload 140. Additionally or alternatively, insome examples, the simulated network traffic repository included in therepositories 146 may store a library of different test traffic files fordifferent types of workloads, and the traffic simulator 305 may select anetwork traffic file for the workload 140 from the repository based onthe type of the workload 140.

In the illustrated example, the traffic simulator 305 generates thesimulated network traffic to validate the updated TSN schedule bycombining the previously monitored network traffic, which is associatedwith prior operation of the softswitch 106, with the test traffic fileassociated with the new workload 140. The traffic simulator 305 thenapplies the simulated network traffic to the duplicate softswitch 205 bysimulating appropriate virtual sources and sinks to send and receive thesimulated network traffic processed by the duplicate softswitch 205. Inthe illustrated example, the traffic simulator 305 also implements avirtual sink to receive network traffic sent by the workload 140 (and VM142), which is operating in test mode, to process simulated networktraffic received by the VM 142 and workload 140 (e.g., based on the testtraffic file). The network node configurator 138 then monitors trafficperformance metrics associated with the simulated network trafficprocessed by the duplicate softswitch 205 based on the updated TSNschedule. For example, one or more virtual network sinks implemented bythe traffic simulator 305 may be configured to receive the simulatednetwork traffic traversing the duplicate softswitch 205 and generatetraffic performance metrics (e.g., such as packet jitter, packetlatency, etc.) from the simulated network traffic before discarding thesimulated network packets. For example, the virtual sinks(s) maygenerate the traffic performance metrics for the simulated networktraffic associated with (e.g., receive and/or transmitted) by theworkload 140 (also referred to as the simulated traffic performancemetrics for the workload 140). Additionally or alternatively, in someexamples, the virtual sinks(s) may generate the traffic performancemetrics for the respective simulated network traffic associated with(e.g., previously monitored for) one, or more, or all of the otherworkloads 108, 110, 112 (also referred to as the simulated trafficperformance metrics for the workloads 108, 110, 112). Additionally oralternatively, in some examples, the network node configurator 138and/or traffic simulator 305 monitor switch metrics associated withoperation of the duplicate softswitch 205 to process the simulatednetwork traffic (e.g., such as buffer/queue utilization and/or overflowfor different traffic classes specified by the updated TSN schedule,detected violations of the gate structure specified by the updated TSNschedule, etc.). The application of simulated network traffic to theduplicate softswitch 205, and the corresponding monitoring of theperformance metrics, is represented by the directed line 310 in theexample of FIG. 3.

In the illustrated example, the network node configurator 138 monitorsthe traffic performance metrics and switch metrics, if available,associated with the simulated network traffic processed on the duplicatesoftswitch 205 based on the updated TSN schedule and compares themonitored performance metrics to one or more sets of constraints tovalidate the updated TSN schedule. For example, the constraints maycorrespond to one or more of the network communication schedulingrequirements specified in the VIFD 158 for the new workload 140 beingdeployed to the compute node 104. In some such examples, the centraluser configurator 152 and/or the central network configurator 154provide (e.g., with the deployment of the updated TSN schedule to thecompute node 104) one or more sets of network performance constraintsfor the new workload 140, which are parsed from the VIFD 158, to thenetwork node configurator 138. The network node configurator 138 canthen store the one or more sets of network performance constraints forthe workload 140 in a workload scheduling and metrics specificationrepository included in the repositories 146. Likewise, the workloadscheduling and metrics specification repository included in therepositories 146 may contain stored sets of network performanceconstraints previously received from the central user configurator 152and/or the central network configurator 154 for the other workloads 108,110 and 112. Examples of such network performance constraints include aframe spacing target, mean packet latency target, and upper packetlatency bound, etc. The workload scheduling and metrics specificationrepository included in the repositories 146 may also include targets forthe switch metrics monitored by the network node configurator 138.

In some examples, the network performance constraints obtained for theworkload 140 (and previously for the other workloads 108, 110, 112) areidentified to indicate the importance, or severity, of the constraint.For example, a constraint may be identified as a first type ofconstraint corresponding to a hard constraint that must be met by themonitored traffic metrics in order for the associated workload for theupdated TSN schedule to be considered valid, or as a second type ofconstraint corresponding to a soft constraint that is desired to be metbut not required in order for the updated TSN schedule to be consideredvalid. In some such examples, the network node configurator 138 groupsthe network performance constraints to be evaluated into a first set ofconstraints including the identified first type of constraints (e.g.,hard constraints) and a second set of constraints including theidentified second type of constraints (e.g., soft constraints). In somesuch examples, if the simulated network traffic has monitored trafficmetrics that meet the first set of constraints (e.g., hard constraints),the network node configurator 138 may spend an amount of time up to abounded time limit to adjust the configuration of the duplicatesoftswitch 205 to meet one or more of the constraints included in thesecond set of constraints (e.g., the soft constraints). In someexamples, the bounded time limit, also referred to as an optimizationtime limit, is specified in the VIFD 158 for the new workload 140 beingdeployed to the compute node 104, and is provided to the network nodeconfigurator 138 by the central user configurator 152 and/or the centralnetwork configurator 154 with the other constraints. In some suchexamples, the optimization time limit may be related to an amount ofdelay that can be tolerated while the workload 140 is being deployed tothe compute node 104.

In the illustrated example, the network node configurator 138 comparesthe simulated traffic performance metrics for workload 140 and, in someexamples, the simulated traffic performance metrics for the otherworkloads 108, 110, 112 processed by the duplicate softswitch 205, withthe respective sets of constraints for the corresponding workloads todetermine whether the updated TSN schedule implemented by the duplicatesoftswitch 205 is valid. In some examples, the network node configurator138 may also compare the switch metrics determined for the duplicatesoftswitch 205 when processing the simulated network traffic tocorresponding targets to determine whether the updated TSN scheduleimplemented by the duplicate softswitch 205 is valid. In some examplesin which the new workload 140 is associated with a first set ofconstraints corresponding to hard constraints and a second set ofconstraints corresponding to soft constraints, the network nodeconfigurator 138 determines the updated TSN schedule is valid if thesimulated traffic performance metrics associated with the workload 140satisfy the first set of constraints. In some such examples, if theexisting workloads 108, 110, 112 are also associated with respectivefirst sets of constraints corresponding to hard constraints and secondsset of constraints corresponding to soft constraints, the network nodeconfigurator 138 determines the updated TSN schedule is valid if thesimulated traffic performance metrics associated with the respectiveworkloads 108, 110, 112 also satisfy their corresponding first sets ofconstraints. For example, the first sets of constraints corresponding tohard constraints may be constraints that, if met, indicate thatdeterministic packet scheduling has been achieved with the updated TSNschedule and that threshold network performance targets for thecorresponding workloads are met.

In some examples, after the network node configurator 138 determines theupdated TSN schedule is valid because the first sets of constraintscorresponding to hard constraints are met, the network node configurator138 then determines whether the second set of constraints correspondingto soft constraints for the workload 140. In some examples, the networknode configurator 138 also determines whether the respective second setsof constraints corresponding to soft constraints for the workloads 108,110, 112 have also been met. If one or more of the soft constraints inthe second set of constraints have not been met, the network nodeconfigurator 138 adjusts the configuration of the duplicate softswitch205 to enable one or more of the soft constraints to be met. Forexample, the duplicate softswitch 205 may include multiple data buffers(e.g., queues) assigned to different data classes defined by the TSNschedule, which the duplicate softswitch 205 gates on and off to allowtraffic to packets in the buffers to traverse the softswitch 205 to meettiming requirements specified by the updated TSN schedule. To adjust theduplicate softswitch 205 such that one or more of the soft constraintscan be met, the network node configurator 138 may adjust the number ofdata buffers (e.g., queues) assigned to the different data classesdefined by the TSN schedule, adjust when and/or how often and/or for howlong different ones of the data buffers (e.g., queues) are gated on toallow their respective packets to traverse the softswitch 205, etc. Insome examples, the network node configurator 138 adjusts the duplicatesoftswitch 205 iteratively such that ones of the soft constraints aremet in priority weighting order, with higher soft constraints beingoptimized before lower soft constraints, resulting in iterativeoptimization of the soft constraints. In some examples, the network nodeconfigurator 138 continues adjusting the configuration of the duplicatesoftswitch 205 iteratively until all soft constraints are met or untilthe bounded time limit for adjusting the configuration of the duplicatesoftswitch 205 is reached. At this point, the updated TSN schedule andconfiguration of the duplicate softswitch 205 are finalized and ready tobe deployed on the compute node 104

Turning to FIG. 4, if the network node configurator 138 determines theupdated TSN schedule is not valid (e.g., because one or more of thefirst set of constraints corresponding to hard constraints, such as aframe delivery deadline, are not met by the updated TSN schedule), thenetwork node configurator 138 generates a failure message and sends thefailure message to the central configuration controller 102 for receiptby the central user configurator 152 and the orchestrator 150. Inresponse to the failure message, the orchestrator 150 causes the newvirtualized workload 140 instance to be deleted from the compute node104 (e.g., by deleting its VM 142). The network node configurator 138also deletes the updated TSN schedule and the duplicate softswitch 205from the compute node 104.

However, if the network node configurator 138 determines the updated TSNschedule is valid (e.g., because the first set of constraintscorresponding to hard constraints, such as a frame delivery deadline,are met by the updated TSN schedule), the network node configurator 138generates a success message and sends the success message to the centralconfiguration controller 102 for receipt by the central userconfigurator 152 and the orchestrator 150. The network node configurator138 is also responsible for replacing the existing softswitch 106 withthe new softswitch 205 and transitioning the new workload 140 and theexisting workloads 108, 110 and 112 to the new softswitch 205.

For example, as shown in the example of FIG. 4, the network nodeconfigurator 138 connects the newly configured softswitch 205implementing the updated TSN schedule to the NIC 122 of the compute nodevia the DPDK 126 (e.g., by updating the configuration specifications ofthe respective softswitches 106 and 205). The network node configurator138 also adds new port connections to the respective VMs/containers 128,130, 132 implementing the corresponding existing workloads 108, 110,112, binds the new ports to the new softswitch 205, and deletes theprevious port bindings associated with the softswitch 106, as shown(e.g., by updating the configuration files for the VMs/containers 128,130, 132 and the softswitches 106 and 205). The network nodeconfigurator 138 also configures the new workload 140 hosted by the VM142 to operate in an operational mode instead of test mode (e.g., bysetting an appropriate configuration setting, value, field, etc.). Thenetwork node configurator 138 also stores the configurationspecification for the new softswitch 205 in the softswitch specificationrepository included in the repositories 146 and/or reports theconfiguration specification for the new softswitch 205 to the centralconfiguration controller 102.

Next, turning to FIG. 5, the network node configurator 138 deletes theold softswitch 106 from the compute node 104 and deletes itsconfiguration specification from the softswitch specification repositoryincluded in the repositories 146. In this manner, the network nodeconfigurator 138 replaces the old softswitch 106 implementing the oldTSN schedule with the new softswitch 205 implementing the updated TSNschedule. Because the switchover is performed after the updated TSNschedule implemented by the new softswitch 205 is verified with thesimulated network traffic, and can be accomplished quickly by updatingconfiguration specification files for the VMs/containers 128, 130, 132and softswitches 106, 205, the existing workloads 108, 110 and 112 canexperience negligible downtime during the switchover. In the illustratedexample, after the switchover from the old softswitch 106 implementingthe old TSN schedule to the new softswitch 205 implementing the updatedTSN schedule, the traffic simulator 305 monitors the network traffictraversing the new softswitch 205 (e.g., which is associated with theworkloads 108, 110, 112 and 140) and stores the monitored networktraffic (e.g., as one or more PCAP files) in the simulated networktraffic repository included in the repositories 146. This monitorednetwork traffic stored in the simulated network traffic repositoryincluded in the repositories 146 can later be used, as described above,when another updated TSN schedule is to be deployed to the compute node104.

A block diagram of an example implementation of the network nodeconfigurator 138 of FIGS. 1-5 is illustrated in FIG. 7. The examplenetwork node configurator 138 of FIG. 7 includes an example softswitchinstantiator 705 to instantiate the duplicate softswitch 205 on thecompute node 104 in response to receiving the updated TSN schedule, asdescribed above. The network node configurator 138 of FIG. 7 includes anexample TSN schedule configure 710 to configure the duplicate softswitch205 to implement the updated TSN schedule, as described above. Thenetwork node configurator 138 of FIG. 7 includes the example trafficsimulator 305 and an example TSN schedule validator 715 to validate theupdated TSN schedule implemented by the duplicate softswitch 205, asdescribed above. The network node configurator 138 of FIG. 7 includes anexample softswitch replacer 720 to replace the existing softswitch 106with the new softswitch 205 on the compute node 104 in response tosuccessful validation of the updated TSN schedule, as described above.

While example manners of implementing the example central configurationcontroller 102 and the example network node configurator 138 areillustrated in FIGS. 1-7, one or more of the elements, processes and/ordevices illustrated in FIGS. 1-7 may be combined, divided, re-arranged,omitted, eliminated and/or implemented in any other way. Further, theexample orchestrator 150, the example central user configurator 152, theexample central network configurator 154, the example scheduler 156, theexample traffic simulator 305, the example softswitch instantiator 705,the example TSN schedule configure 710, the example TSN schedulevalidator 715, the example softswitch replacer 720 and/or, moregenerally, the example central configuration controller 102 and theexample network node configurator 138 of FIGS. 1-7 may be implemented byhardware, software, firmware and/or any combination of hardware,software and/or firmware. Thus, for example, any of the exampleorchestrator 150, the example central user configurator 152, the examplecentral network configurator 154, the example scheduler 156, the exampletraffic simulator 305, the example softswitch instantiator 705, theexample TSN schedule configure 710, the example TSN schedule validator715, the example softswitch replacer 720 and/or, more generally, theexample central configuration controller 102 and the example networknode configurator 138 could be implemented by one or more analog ordigital circuit(s), logic circuits, programmable processor(s),programmable controller(s), graphics processing unit(s) (GPU(s)),digital signal processor(s) (DSP(s)), application specific integratedcircuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), fieldprogrammable gate arrays (FPGAs) and/or field programmable logicdevice(s) (FPLD(s)). When reading any of the apparatus or system claimsof this patent to cover a purely software and/or firmwareimplementation, at least one of the example central configurationcontroller 102, the example network node configurator 138, the exampleorchestrator 150, the example central user configurator 152, the examplecentral network configurator 154, the example scheduler 156, the exampletraffic simulator 305, the example softswitch instantiator 705, theexample TSN schedule configure 710, the example TSN schedule validator715 and/or the example softswitch replacer 720 is/are hereby expresslydefined to include a non-transitory computer readable storage device orstorage disk such as a memory, a digital versatile disk (DVD), a compactdisk (CD), a Blu-ray disk, etc. including the software and/or firmware.Further still, the example central configuration controller 102 and/orthe example network node configurator 138 of FIGS. 1-7 may include oneor more elements, processes and/or devices in addition to, or insteadof, those illustrated in FIGS. 1-7, and/or may include more than one ofany or all of the illustrated elements, processes and devices. As usedherein, the phrase “in communication,” including variations thereof,encompasses direct communication and/or indirect communication throughone or more intermediary components, and does not require directphysical (e.g., wired) communication and/or constant communication, butrather additionally includes selective communication at periodicintervals, scheduled intervals, aperiodic intervals, and/or one-timeevents.

Flowcharts and pseudocode representative of example hardware logic,machine readable instructions, hardware implemented state machines,and/or any combination thereof for implementing the example centralconfiguration controller 102 and the example network node configurator138 are shown in FIGS. 8-14. In these examples, the machine readableinstructions may be one or more executable programs or portion(s) of anexecutable program for execution by a computer processor, such as theprocessor 1512 and/or 1612 shown in the example processor platforms 1500and 1600 discussed below in connection with FIGS. 15-16. The one or moreprograms, or portion(s) thereof, may be embodied in software stored on anon-transitory computer readable storage medium such as a CD-ROM, afloppy disk, a hard drive, a DVD, a Blu-ray disk™, or a memoryassociated with the processors 1512 and/or 1612, but the entire programor programs and/or parts thereof could alternatively be executed by adevice other than the processors 1512 and/or 1612, and/or embodied infirmware or dedicated hardware. Further, although the example program(s)is(are) described with reference to the flowcharts and pseudocodeillustrated in FIGS. 8-14, many other methods of implementing theexample central configuration controller 102 and/or the example networknode configurator 138 may alternatively be used. For example, withreference to the flowcharts and pseudocode illustrated in FIGS. 8-14,the order of execution of the blocks may be changed, and/or some of theblocks described may be changed, eliminated, combined and/or subdividedinto multiple blocks. Additionally or alternatively, any or all of theblocks may be implemented by one or more hardware circuits (e.g.,discrete and/or integrated analog and/or digital circuitry, an FPGA, anASIC, a comparator, an operational-amplifier (op-amp), a logic circuit,etc.) structured to perform the corresponding operation withoutexecuting software or firmware.

The machine readable instructions described herein may be stored in oneor more of a compressed format, an encrypted format, a fragmentedformat, a compiled format, an executable format, a packaged format, etc.Machine readable instructions as described herein may be stored as data(e.g., portions of instructions, code, representations of code, etc.)that may be utilized to create, manufacture, and/or produce machineexecutable instructions. For example, the machine readable instructionsmay be fragmented and stored on one or more storage devices and/orcomputing devices (e.g., servers). The machine readable instructions mayrequire one or more of installation, modification, adaptation, updating,combining, supplementing, configuring, decryption, decompression,unpacking, distribution, reassignment, compilation, etc. in order tomake them directly readable, interpretable, and/or executable by acomputing device and/or other machine. For example, the machine readableinstructions may be stored in multiple parts, which are individuallycompressed, encrypted, and stored on separate computing devices, whereinthe parts when decrypted, decompressed, and combined form a set ofexecutable instructions that implement a program such as that describedherein.

In another example, the machine readable instructions may be stored in astate in which they may be read by a computer, but require addition of alibrary (e.g., a dynamic link library (DLL)), a software development kit(SDK), an application programming interface (API), etc. in order toexecute the instructions on a particular computing device or otherdevice. In another example, the machine readable instructions may needto be configured (e.g., settings stored, data input, network addressesrecorded, etc.) before the machine readable instructions and/or thecorresponding program(s) can be executed in whole or in part. Thus, thedisclosed machine readable instructions and/or corresponding program(s)are intended to encompass such machine readable instructions and/orprogram(s) regardless of the particular format or state of the machinereadable instructions and/or program(s) when stored or otherwise at restor in transit.

The machine readable instructions described herein can be represented byany past, present, or future instruction language, scripting language,programming language, etc. For example, the machine readableinstructions may be represented using any of the following languages: C,C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language(HTML), Structured Query Language (SQL), Swift, etc.

As mentioned above, the example processes of FIGS. 8-14 may beimplemented using executable instructions (e.g., computer and/or machinereadable instructions) stored on a non-transitory computer and/ormachine readable medium such as a hard disk drive, a flash memory, aread-only memory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage device or storage disk inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, for brief instances, for temporarily buffering,and/or for caching of the information). As used herein, the termnon-transitory computer readable medium is expressly defined to includeany type of computer readable storage device and/or storage disk and toexclude propagating signals and to exclude transmission media. Also, asused herein, the terms “computer readable” and “machine readable” areconsidered equivalent unless indicated otherwise.

“Including” and “comprising” (and all forms and tenses thereof) are usedherein to be open ended terms. Thus, whenever a claim employs any formof “include” or “comprise” (e.g., comprises, includes, comprising,including, having, etc.) as a preamble or within a claim recitation ofany kind, it is to be understood that additional elements, terms, etc.may be present without falling outside the scope of the correspondingclaim or recitation. As used herein, when the phrase “at least” is usedas the transition term in, for example, a preamble of a claim, it isopen-ended in the same manner as the term “comprising” and “including”are open ended. The term “and/or” when used, for example, in a form suchas A, B, and/or C refers to any combination or subset of A, B, C such as(1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) Bwith C, and (7) A with B and with C. As used herein in the context ofdescribing structures, components, items, objects and/or things, thephrase “at least one of A and B” is intended to refer to implementationsincluding any of (1) at least one A, (2) at least one B, and (3) atleast one A and at least one B. Similarly, as used herein in the contextof describing structures, components, items, objects and/or things, thephrase “at least one of A or B” is intended to refer to implementationsincluding any of (1) at least one A, (2) at least one B, and (3) atleast one A and at least one B. As used herein in the context ofdescribing the performance or execution of processes, instructions,actions, activities and/or steps, the phrase “at least one of A and B”is intended to refer to implementations including any of (1) at leastone A, (2) at least one B, and (3) at least one A and at least one B.Similarly, as used herein in the context of describing the performanceor execution of processes, instructions, actions, activities and/orsteps, the phrase “at least one of A or B” is intended to refer toimplementations including any of (1) at least one A, (2) at least one B,and (3) at least one A and at least one B.

As used herein, singular references (e.g., “a”, “an”, “first”, “second”,etc.) do not exclude a plurality. The term “a” or “an” entity, as usedherein, refers to one or more of that entity. The terms “a” (or “an”),“one or more”, and “at least one” can be used interchangeably herein.Furthermore, although individually listed, a plurality of means,elements or method actions may be implemented by, e.g., a single unit orprocessor. Additionally, although individual features may be included indifferent examples or claims, these may possibly be combined, and theinclusion in different examples or claims does not imply that acombination of features is not feasible and/or advantageous.

An example program 800 that may be executed to implement the examplecentral configuration controller 102 of FIG. 1 is represented by theflowchart shown in FIG. 8. With reference to the preceding figures andassociated written descriptions, the example program 800 beginsexecution at block 805 at which the central configuration controller 102accesses the VIFD 158 specifying the new workload 140 to deploy to thecompute node 104. At block 810, the orchestrator 150 of the centralconfiguration controller 102 parses the VIFD 158 to determine a VMconfiguration specification to implement the workload 140, as describedabove. At block 815, the central user configurator 152 of the centralconfiguration controller 102 parses the VIFD to determine a set ofparameters for an updated TSN schedule to accommodate the workload 140,as described above. At block 820, the central network configurator 154of the central configuration controller 102 determines, as describedabove, the updated TSN schedule based on the set of parameters parsedfrom the VIFD 158 at block 815. At block 825, the orchestrator 150 sendsthe VM configuration specification and a corresponding test traffic fileto the compute node 104 to deploy the workload 140 at the compute node104, as described above. At block 830, the central network configurator154 sends the updated TSN schedule to the compute node for deployment atthe compute node 104, as described above.

At block 840, the central configuration controller 102 later receives amessage, as described above, which indicates a deployment result fordeploying the workload 140 and the updated TSN schedule at the computenode 104. If, at block 840, the central configuration controller 102determines the message indicates the updated TSN schedule was notdeployable (e.g., was found to be invalid), processing proceeds to block845; otherwise processing proceeds to block 850. At block 845, theorchestrator 150 deletes the VM configuration specification for theworkload 140 and the central network configurator 154 deletes theupdated TSN schedule, as described above, which cancels the attempt todeploy the workload 140 and the updated TSN schedule to the compute node104. At block 850, the orchestrator 150 retains the VM configurationspecification for the workload 140 and the central network configurator154 retains the updated TSN schedule, as described above, which tracksthe successful deployment of the workload 140 and the updated TSNschedule to the compute node 104.

An example program 900 that may be executed to implement the examplenetwork node configurator 138 of FIGS. 1-5 and/or 7 is represented bythe flowchart shown in FIG. 9. With reference to the preceding figuresand associated written descriptions, the example program 900 beginsexecution at block 905 at which the network node configurator 138accesses a VM configuration specification and associated test trafficfile received from the central configuration controller 102 for the newworkload 140 to be deployed at the compute node 104, as described above.At block 910, the network node configurator 138 accesses an updated TSNschedule received from the central configuration controller 102 forimplementation by the softswitch 106 on the compute node 104, asdescribed above. At block 915, the softswitch instantiator 705 of thenetwork node configurator 138 deploys the duplicate softswitch 205 onthe compute node 104 based on (e.g., to match) a first configuration ofthe softswitch 106 executing on the compute node 104, as describedabove. At block 920, the TSN schedule configure 710 of the network nodeconfigurator 138 configures the duplicate softswitch 205 to implementthe updated TSN schedule, as described above. At block 925, the TSNschedule validator 715 of the network node configurator 138 determineswhether a first set of constraints (e.g., hard constraints) is met forsimulated network traffic processed by the duplicate softswitch 205based on the updated TSN schedule, as described above. An exampleprogram 925P that may be executed to implement the processing at block925 is illustrated in FIG. 10, which is described below.

If the first set of constraints (e.g., hard constraints) are met,processing proceeds to block 935; otherwise processing proceeds to block940. At block 940, the network node configurator 138 determines theupdated TSN schedule is invalid and, thus, deletes the duplicatesoftswitch 205 and the VM 142 that was deployed to implement theworkload 140, as described above. At block 945, the network nodeconfigurator 138 reports a deployment failure status message to thecentral configuration controller 102, as described above.

Conversely, at block 935, the network node configurator 138 determinesthe updated TSN schedule is valid and, thus, adjusts the secondconfiguration associated with the duplicate softswitch 205 to satisfyone or more of a second set of constraints (e.g., soft constraints) tobe met for the simulated network traffic processed by the duplicatesoftswitch 205 based on the updated TSN schedule, as described above. Atblock, the softswitch replacer 720 of the network node configurator 138replaces the existing softswitch 106 with the new softswitch 205, asdescribe above. An example program 950P that may be executed toimplement the processing at block 950 is illustrated in FIG. 12, whichis described below. At block 955, the network node configurator 138reports a deployment success status message to the central configurationcontroller 102, as described above.

An example program 925P that may be executed to implement the processingat block 925 of FIG. 9 is illustrated in FIG. 10. With reference to thepreceding figures and associated written descriptions, the exampleprogram 925P begins execution at block 1005 at which the example TSNschedule validator 715 of the network node configurator 138 connects aport of the VM 142, which is being deployed to implement the workload140, to the duplicate softswitch 205, as described above. At block 1010,the TSN schedule validator 715 configures the workload 140 hosted by theVM 142 to operate in test mode, as described above. At block 1015, theTSN schedule validator 715 invokes the traffic simulator 305 to applysimulated network traffic to the duplicate softswitch 205, as describedabove. At block 1020, the TSN schedule validator 715 monitors metricsassociated with the simulate network traffic processed by the softswitch205 based on the updated TSN schedule, as described above. At block1025, the TSN schedule validator 715 compares the monitored metrics tothe first set of constraints (e.g., hard constraints), as describedabove. Example pseudocode 1025S that may be executed to implement theprocessing at block 1025 is illustrated in FIG. 11.

An example program 950P that may be executed to implement the processingat block 950 of FIG. 9 is illustrated in FIG. 12. With reference to thepreceding figures and associated written descriptions, the exampleprogram 950P begins execution at block 1205 at which the softswitchreplacer 720 of the network node configurator 138 connects the newsoftswitch 205 to the NIC 122 of the compute node 104, as describedabove. At block 1210, the softswitch replacer 720 adds respective newport connections to the corresponding existing VMs/containers 128, 130,132 implemented the existing workloads 108, 110, 112 on the compute node104, as described above. At block 1215, the softswitch replacer 720binds the new port connections of the VMs/containers 128, 130, 132 tothe new softswitch 205, as described above. At block 1220, thesoftswitch replacer 720 deletes the prior port connections of theVMs/containers 128, 130, 132 that connected to the softswitch 106, asdescribed above. At block 1225, the softswitch replacer 720 sets the newworkload 140 hosted by the new VM 142, which is already connected to thenew softswitch 205, to operational mode, as described above. At block1230, the softswitch replacer 720 deletes the softswitch 106 from thecompute node 104, as described above. At block 1235, the softswitchreplacer 720 invokes the traffic simulator 305 to monitor the networktraffic processed by the new softswitch 205 based on the updated TSNschedule to generate new simulated network traffic to be used tovalidate future TSN schedule updates, as described above.

An example program 1300 that may be executed to implement the examplecentral configuration controller 102 and the example network nodeconfigurator 138 is represented by the flowchart shown in FIGS. 13-14.With reference to the preceding figures and associated writtendescriptions, the example program 1300 begins execution at block 1302 atwhich the central user configurator 152 of the central configurationcontroller 102 accesses and parses the VIFD 158 for the workload 140corresponding to a new service deployment to obtain the networkscheduling requirements for the workload 140, as described above. Atblock 1304, the central network configurator 154 determines an updatedTSN schedule based on the network scheduling requirements parsed fromthe VIFD 158, as described. At block 1306, the network node configurator138 receives from the central network configurator 154 the updated TSNschedule and set(s) of constraints to be evaluated to validate theupdated TSN schedule on the compute node 104, as described above. Inparallel, at block 1308, the orchestrator 150 of the centralconfiguration controller 102 parses the VIFD 158 for the workload 140 todetermine the workload deployment requirements to be used to create theVM 142 (or container) to be deployed to implement the new workload 140,as described above. Processing then proceeds to an example subroutine1310, which is illustrated in FIG. 14.

The subroutine 1310 of FIG. 14 begins execution at block 1312 at whichthe orchestrator 150 deploys the VM 142 on the compute node 104 toimplement the workload 140 at the compute node 104. At block 1314, theorchestrator 150 sends a test traffic file for the workload 140 to thenetwork node configurator 138, as described above. At block 1316, thenetwork node configurator 138 receives, from the central networkconfigurator 154, the updated TSN schedule and the set(s) of constraintsparsed from VIFD 158, and initiates deployment of the duplicatesoftswitch 206, as described above. At block 1318, the central networkconfigurator 154 deploys, as described above, the duplicate softswitch206 based on (e.g., to match) the configuration specification obtainedfor the existing softswitch 106 from the softswitch specificationrepository included in the repositories 146 (represented by block 1320in FIG. 14).

At block 1322, the network node configurator 138 connects the VM 142implementing the new workload 140 to the duplicate softswitch 205 andsets the workload 140 hosted by the VM 142 to test mode, as describedabove. At block 1324, the network node configurator 138 invokes thetraffic simulator 305 to apply simulated network traffic to theduplicate softswitch 205 to validate the updated TSN schedule, asdescribed above. As described above, the simulated network traffic isobtained from the simulated network traffic repository included in therepositories 146 (represented by block 1326 in FIG. 14). As describedabove, the simulated network traffic is collected by one or more virtualnetwork sinks which determine traffic performance metrics associatedwith the simulated network traffic processed by the duplicate softswitch205 based on the updated TSN schedule (block 1328). At block 1330, thenetwork node configurator 138 also monitors switch metrics associatedwith processing of the simulated network traffic by the duplicatesoftswitch 205, as described above. When the simulated network trafficis complete (block 1332), processing proceeds to block 1334.

At block 1334, the network node configurator 138 compares, as describedabove, the monitored metrics with the first set of constraints (e.g.,hard constraints) obtained from the workload scheduling and metricsspecification repository included in the repositories 146 (representedby block 1336 in FIG. 14). At block 1338, the network node configurator138 determines, as described above, whether the first set of constraints(e.g., hard constraints) is met and, thus, whether the updated TSNschedule is valid. If the updated TSN schedule is not valid because oneor of the first set of constraints was not met (block 1338), thenprocessing returns from the subroutine 1332 (represented by block 1340in FIG. 14). However, if the updated TSN schedule is valid (block 1338),then at block 1342, the network node configurator 138 adjusts theconfiguration of the new softswitch 205 to cause one or more of thesecond set of constraints (e.g., soft constraints) obtained from theworkload scheduling and metrics specification repository to be met. Atblock 1344, the network node configurator 138 continues to iterativelyadjust perform such constraint optimization until the second set ofconstraints (e.g., soft constraints) is met or the bounded time limit ismet, as described above. Processing then returns from the subroutine1332 (represented by block 1340 in FIG. 14).

Returning to FIG. 13, at block 1346, the network node configurator 138causes processing to proceed to block 1348 if the updated TSN scheduleis determined not to be valid, and causes processing to proceed to block1350 if the updated TSN schedule is determined to be valid. At block1348, the network node configurator 138 generates a deployment failuremessage and transmits the failure message to the central configurationcontroller 102, as described above. At block 1352, the orchestrator 150and the central user configurator 152 receive the deployment failuremessage. At block 1354, the orchestrator 150 and the central userconfigurator 152 deletes the VM 142 implementing the workload 140 andthe updated TSN schedule, as described above.

Conversely, at block 1350, the network node configurator 138 addsrespective new port connections to the corresponding existingVMs/containers 128, 130, 132 implementing the existing workloads 108,110, 112 on the compute node 104, binds the new port connections of theVMs/containers 128, 130, 132 to the new softswitch 205, and deletes theprior port connections of the VMs/containers 128, 130, 132 thatconnected to the softswitch 106, as described above. At block 1358, thenetwork node configurator 138 deletes the softswitch 106 from thecompute node 104, as described above, and deletes the configurationspecification for the softswitch 106 from the softswitch specificationrepository included in the repositories 146 (represented by block 1360of FIG. 13.) At block 1362, the network node configurator 138 invokesthe traffic simulator 305 to monitor, as described above, the networktraffic processed by the new softswitch 205 based on the updated TSNschedule to generate new simulated network traffic to store in thesimulated network traffic repository included in the repositories 146(represented by block 1364 of FIG. 13).

FIG. 15 is a block diagram of an example processor platform 1500structured to execute the instructions of FIG. 8, 13 and/or 14 toimplement the example central configuration controller of FIG. 1. Theprocessor platform 1500 can be, for example, a server, a personalcomputer, a workstation, a self-learning machine (e.g., a neuralnetwork), a mobile device (e.g., a cell phone, a smart phone, a tabletsuch as an iPad™) or any other type of computing device.

The processor platform 1500 of the illustrated example includes aprocessor 1512. The processor 1512 of the illustrated example ishardware. For example, the processor 1512 can be implemented by one ormore integrated circuits, logic circuits, microprocessors, GPUs, DSPs,or controllers from any desired family or manufacturer. The hardwareprocessor 1512 may be a semiconductor based (e.g., silicon based)device. In this example, the processor 1512 implements the orchestrator150, the central user configurator 152, the central network configurator154 and the scheduler 156.

The processor 1512 of the illustrated example includes a local memory1513 (e.g., a cache). The processor 1512 of the illustrated example isin communication with a main memory including a volatile memory 1514 anda non-volatile memory 1516 via a link 1518. The link 1518 may beimplemented by a bus, one or more point-to-point connections, etc., or acombination thereof. The volatile memory 1514 may be implemented bySynchronous Dynamic Random Access Memory (SDRAM), Dynamic Random AccessMemory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or anyother type of random access memory device. The non-volatile memory 1516may be implemented by flash memory and/or any other desired type ofmemory device. Access to the main memory 1514, 1516 is controlled by amemory controller.

The processor platform 1500 of the illustrated example also includes aninterface circuit 1520. The interface circuit 1520 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), a Bluetooth® interface, a near fieldcommunication (NFC) interface, and/or a PCI express interface.

In the illustrated example, one or more input devices 1522 are connectedto the interface circuit 1520. The input device(s) 1522 permit(s) a userto enter data and/or commands into the processor 1512. The inputdevice(s) can be implemented by, for example, an audio sensor, amicrophone, a camera (still or video), a keyboard, a button, a mouse, atouchscreen, a track-pad, a trackball, a trackbar (such as an isopoint),a voice recognition system and/or any other human-machine interface.Also, many systems, such as the processor platform 1500, can allow theuser to control the computer system and provide data to the computerusing physical gestures, such as, but not limited to, hand or bodymovements, facial expressions, and face recognition.

One or more output devices 1524 are also connected to the interfacecircuit 1520 of the illustrated example. The output devices 1524 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay (LCD), a cathode ray tube display (CRT), an in-place switching(IPS) display, a touchscreen, etc.), a tactile output device, a printerand/or speakers(s). The interface circuit 1520 of the illustratedexample, thus, typically includes a graphics driver card, a graphicsdriver chip and/or a graphics driver processor.

The interface circuit 1520 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem, a residential gateway, a wireless access point, and/or a networkinterface to facilitate exchange of data with external machines (e.g.,computing devices of any kind) via a network 1526, such as the network145. The communication can be via, for example, an Ethernet connection,a digital subscriber line (DSL) connection, a telephone line connection,a coaxial cable system, a satellite system, a line-of-site wirelesssystem, a cellular telephone system, etc.

The processor platform 1500 of the illustrated example also includes oneor more mass storage devices 1528 for storing software and/or data.Examples of such mass storage devices 1528 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, redundantarray of independent disks (RAID) systems, and digital versatile disk(DVD) drives. In some examples, the volatile memory 1514 and/or the massstorage device 1528 may store the VIFDs processed by the centralconfiguration controller 102.

The machine executable instructions 1532 corresponding to theinstructions of FIGS. 8, 13 and/or 14 may be stored in the mass storagedevice 1528, in the volatile memory 1514, in the non-volatile memory1516, in the local memory 1513 and/or on a removable non-transitorycomputer readable storage medium, such as a CD or DVD 1536.

FIG. 16 is a block diagram of an example processor platform 1600structured to execute the instructions of FIGS. 9, 10, 11, 12, 13 and/or14 to implement the example network node configurator 138 of FIGS. 1-5and/or 7. The processor platform 1600 can be, for example, a server, apersonal computer, a workstation, a self-learning machine (e.g., aneural network), a mobile device (e.g., a cell phone, a smart phone, atablet such as an iPad™) or any other type of computing device.

The processor platform 1600 of the illustrated example includes aprocessor 1612. The processor 1612 of the illustrated example ishardware. For example, the processor 1612 can be implemented by one ormore integrated circuits, logic circuits, microprocessors, GPUs, DSPs,or controllers from any desired family or manufacturer. The hardwareprocessor 1612 may be a semiconductor based (e.g., silicon based)device. In this example, the processor 1612 implements the trafficsimulator 305, the softswitch instantiator 705, the TSN scheduleconfigure 710, the TSN schedule validator 715 and the softswitchreplacer 720.

The processor 1612 of the illustrated example includes a local memory1613 (e.g., a cache). The processor 1612 of the illustrated example isin communication with a main memory including a volatile memory 1614 anda non-volatile memory 1616 via a link 1618. The link 1618 may beimplemented by a bus, one or more point-to-point connections, etc., or acombination thereof. The volatile memory 1614 may be implemented bySDRAM, DRAM, RDRAM® and/or any other type of random access memorydevice. The non-volatile memory 1616 may be implemented by flash memoryand/or any other desired type of memory device. Access to the mainmemory 1614, 1616 is controlled by a memory controller.

The processor platform 1600 of the illustrated example also includes aninterface circuit 1620. The interface circuit 1620 may be implemented byany type of interface standard, such as an Ethernet interface, a USB, aBluetooth® interface, an NFC interface, and/or a PCI express interface.

In the illustrated example, one or more input devices 1622 are connectedto the interface circuit 1620. The input device(s) 1622 permit(s) a userto enter data and/or commands into the processor 1612. The inputdevice(s) can be implemented by, for example, an audio sensor, amicrophone, a camera (still or video), a keyboard, a button, a mouse, atouchscreen, a track-pad, a trackball, a trackbar (such as an isopoint),a voice recognition system and/or any other human-machine interface.Also, many systems, such as the processor platform 1600, can allow theuser to control the computer system and provide data to the computerusing physical gestures, such as, but not limited to, hand or bodymovements, facial expressions, and face recognition.

One or more output devices 1624 are also connected to the interfacecircuit 1620 of the illustrated example. The output devices 1624 can beimplemented, for example, by display devices (e.g., an LED, an OLED, anLCD, a CRT display, an IPS display, a touchscreen, etc.), a tactileoutput device, a printer and/or speakers(s). The interface circuit 1620of the illustrated example, thus, typically includes a graphics drivercard, a graphics driver chip and/or a graphics driver processor.

The interface circuit 1620 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem, a residential gateway, a wireless access point, and/or a networkinterface to facilitate exchange of data with external machines (e.g.,computing devices of any kind) via a network 1626, such as the network145. The communication can be via, for example, an Ethernet connection,a DSL connection, a telephone line connection, a coaxial cable system, asatellite system, a line-of-site wireless system, a cellular telephonesystem, etc.

The processor platform 1600 of the illustrated example also includes oneor more mass storage devices 1628 for storing software and/or data.Examples of such mass storage devices 1628 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAIDsystems, and DVD drives. In some examples, the volatile memory 1614and/or the mass storage device 1628 may implement one or more of therepositories 146.

The machine executable instructions 1632 corresponding to theinstructions of FIGS. 9, 10, 11, 12, 13 and/or 14 may be stored in themass storage device 1628, in the volatile memory 1614, in thenon-volatile memory 1616, in the local memory 1613 and/or on a removablenon-transitory computer readable storage medium, such as a CD or DVD1636.

From the foregoing, it will be appreciated that example methods,apparatus and articles of manufacture have been disclosed that change aTSN schedule implemented by a softswitch on a compute node operating ina time sensitive network. Disclosed example methods, apparatus andarticles of manufacture improve the efficiency of the compute node byusing a duplicate softswitch, also referred to herein as a digital twinsoftswitch, to enable dynamic changing of the existing TSN scheduleimplemented by the softswitch executing on the compute node, which maybe caused by a new workload being deployed in the time sensitivenetwork, without impacting the deterministic and real-time packetcommunications associated with existing workloads connected to thesoftswitch. Disclosed example methods, apparatus and articles ofmanufacture also utilize the duplicate softswitch (digital twinsoftswitch) to validate an updated TSN schedule in situ with a newworkload being deployed, and can prevent deployment of the updated TSNschedule if a performance issue is detected. Disclosed methods,apparatus and articles of manufacture are accordingly directed to one ormore improvement(s) in the functioning of a computer.

The foregoing disclosure provides example solutions to change a timesensitive networking schedule implemented by a softswitch. The followingfurther examples, which include subject matter such as at least onesoftswitch time sensitive networking schedule changing apparatus, atleast one non-transitory computer readable medium including instructionsthat, when executed, cause at least one processor to change a timesensitive networking schedule implemented by a softswitch, and asoftswitch time sensitive networking schedule changing method, aredisclosed herein. Disclosed examples can be implemented individuallyand/or in one or more combinations.

Example 1 is an apparatus to change a time sensitive networking scheduleimplemented by a first softswitch on a compute node. The apparatus ofexample 1 includes a network node configurator and a traffic simulator.The network node configurator of example 1 is to (i) deploy a secondsoftswitch on the compute node based on a first configurationspecification associated with the first softswitch, (ii) configure thesecond softswitch to implement an updated time sensitive networkingschedule different from the time sensitive networking scheduleimplemented by the first softswitch, and (iii) replace the firstsoftswitch with the second softswitch in response to a determinationthat a first set of constraints is met for simulated network trafficprocessed by the second softswitch based on the updated time sensitivenetworking schedule. The traffic simulator of example 1 is to apply thesimulated network traffic to the second softswitch.

Example 2 includes the subject matter of example 1, wherein the firstsoftswitch is to communicate with respective first ports ofcorresponding ones of a first set of virtual machines on the computenode to provide the first set of virtual machines with access to anetwork that implements time sensitive networking, and to replace thefirst softswitch with the second softswitch, the network nodeconfigurator is to: (i) connect the second softswitch to a networkinterface of the compute node; (ii) add respective second ports tocorresponding ones of the first set of virtual machines; (iii) bind therespective second ports of the corresponding ones of the first set ofvirtual machines to the second softswitch; (iv) delete the respectivefirst ports of the corresponding ones of the first set of virtualmachines; and (v) delete the first softswitch from the compute node.

Example 3 includes the subject matter of example 1 or example 2, whereinthe updated time sensitive networking schedule is to support deploymentof a new virtual machine to the compute node to host a workload, and thenetwork node configurator is to: (i) connect a port of the new virtualmachine to the second softswitch; (ii) configure the workload to operatein a test mode; (iii) monitor a metric associated with the simulatednetwork traffic processed by the second softswitch; and (iv) configurethe workload to operate in an operational mode after the determinationthat the first set of constraints is met for the simulated networktraffic processed by the second softswitch based on the updated timesensitive networking schedule.

Example 4 includes the subject matter of example 3, wherein thesimulated network traffic includes: (i) first simulated network trafficassociated with a first set of virtual machines on the compute node, thefirst set of virtual machines in communication with the firstsoftswitch, the first simulated traffic corresponding to previouslymonitored network traffic obtained during operation of the first set ofvirtual machines; and (ii) second simulated network traffic associatedwith the new virtual machine.

Example 5 includes the subject matter of any one of examples 1 to 4,wherein the network node configurator is to delete the second softswitchand the updated time sensitive networking schedule from the compute nodein response to a determination that the first set of constraints is notmet for the simulated network traffic processed by the second softswitchbased on the updated time sensitive networking schedule.

Example 6 includes the subject matter of any one of examples 1 to 5,wherein the second softswitch is associated with a second configurationspecification, the second configuration specification to correspond tothe first configuration specification when the second softswitch isinitially deployed on the compute node, and in response to thedetermination that the first set of constraints is met for the simulatednetwork traffic, the network node configurator is to adjust the secondconfiguration of the second softswitch to satisfy at least one of asecond set of constraints to be met for the simulated network trafficprocessed by the second softswitch based on the updated time sensitivenetworking schedule.

Example 7 includes the subject matter of example 6, wherein the networknode configurator is to iteratively adjust the second configuration ofthe second softswitch to satisfy other ones of the second set ofconstraints to be met for the simulated network traffic until a timelimit is reached.

Example 8 is at least one non-transitory computer readable mediumcomprising computer readable instructions which, when executed, cause atleast one processor to at least: (i) deploy a second softswitch on acompute node based on a first configuration specification associatedwith a first softswitch on the compute node; (ii) configure the secondsoftswitch to implement a second time sensitive networking scheduledifferent from a first time sensitive networking schedule implemented bythe first softswitch; and (iii) replace the first softswitch with thesecond softswitch in response to a determination that a first set ofconstraints is met for simulated network traffic processed by the secondsoftswitch based on the second time sensitive networking schedule.

Example 9 includes the subject matter of example 8, wherein the firstsoftswitch is to communicate with respective first ports ofcorresponding ones of a first set of virtual machines on the computenode to provide the first set of virtual machines with access to anetwork that implements time sensitive networking, and to replace thefirst softswitch with the second softswitch, the instructions, whenexecuted, cause the at least one processor to: (i) connect the secondsoftswitch to a network interface of the compute node; (ii) addrespective second ports to corresponding ones of the first set ofvirtual machines; (iii) bind the respective second ports of thecorresponding ones of the first set of virtual machines to the secondsoftswitch; (iv) delete the respective first ports of the correspondingones of the first set of virtual machines; and (v) delete the firstsoftswitch from the compute node.

Example 10 includes the subject matter of example 8 or example 9,wherein the second time sensitive networking schedule is to supportdeployment of a new virtual machine to the compute node to host aworkload, and the instructions, when executed, cause the at least oneprocessor to: (i) connect a port of the new virtual machine to thesecond softswitch; (ii) configure the workload to operate in a testmode; (iii) monitor a metric associated with the simulated networktraffic processed by the second softswitch; and (iv) configure theworkload to operate in an operational mode after the determination thatthe first set of constraints is met for the simulated network trafficprocessed by the second softswitch based on the second time sensitivenetworking schedule.

Example 11 includes the subject matter of example 10, wherein thesimulated network traffic includes: (i) first simulated network trafficassociated with a first set of virtual machines on the compute node, thefirst set of virtual machines in communication with the firstsoftswitch, the first simulated traffic corresponding to previouslymonitored network traffic obtained during operation of the first set ofvirtual machines; and (ii) second simulated network traffic associatedwith the new virtual machine.

Example 12 includes the subject matter of any one of examples 8 to 11,wherein the instructions, when executed, cause the at least oneprocessor to delete the second softswitch and the second time sensitivenetworking schedule from the compute node in response to a determinationthat the first set of constraints is not met for the simulated networktraffic processed by the second softswitch based on the second timesensitive networking schedule.

Example 13 includes the subject matter of any one of examples 8 to 12,wherein the second softswitch is associated with a second configurationspecification, the second configuration specification to correspond tothe first configuration specification when the second softswitch isinitially deployed on the compute node, and in response to thedetermination that the first set of constraints is met for the simulatednetwork traffic, the instructions, when executed, cause the at least oneprocessor to adjust the second configuration of the second softswitch tosatisfy at least one of a second set of constraints to be met for thesimulated network traffic processed by the second softswitch based onthe second time sensitive networking schedule.

Example 14 includes the subject matter of example 13, wherein theinstructions, when executed, cause the at least one processor toiteratively adjust the second configuration of the second softswitch tosatisfy other ones of the second set of constraints to be met for thesimulated network traffic until a time limit is reached.

Example 15 is a method to change a time sensitive networking scheduleimplemented by a first softswitch on a compute node. The method of claim15 includes deploying a second softswitch on the compute node based on afirst configuration specification associated with the first softswitch.The method of claim 15 also includes configuring the second softswitchto implement an updated time sensitive networking schedule differentfrom the time sensitive networking schedule implemented by the firstsoftswitch. The method of claim 15 further includes replacing the firstsoftswitch with the second softswitch in response to a determinationthat a first set of constraints is met for simulated network trafficprocessed by the second softswitch based on the updated time sensitivenetworking schedule.

Example 16 includes the subject matter of example 15, wherein the firstsoftswitch is to communicate with respective first ports ofcorresponding ones of a first set of virtual machines on the computenode to provide the first set of virtual machines with access to anetwork that implements time sensitive networking, and replacing thefirst softswitch with the second softswitch includes: (i) connecting thesecond softswitch to a network interface of the compute node; (ii)adding respective second ports to corresponding ones of the first set ofvirtual machines; (iii) binding the respective second ports of thecorresponding ones of the first set of virtual machines to the secondsoftswitch; (iv) deleting the respective first ports of thecorresponding ones of the first set of virtual machines; and (v)deleting the first softswitch from the compute node.

Example 17 includes the subject matter of example 15 or example 16,wherein the updated time sensitive networking schedule is to supportdeployment of a new virtual machine to the compute node to host aworkload, and further including: (i) connecting a port of the newvirtual machine to the second softswitch; (ii) configuring the workloadto operate in a test mode; (iii) monitoring a metric associated with thesimulated network traffic processed by the second softswitch; and (iv)configuring the workload to operate in an operational mode after thedetermination that the first set of constraints is met for the simulatednetwork traffic processed by the second softswitch based on the updatedtime sensitive networking schedule.

Example 18 includes the subject matter of example 17, wherein thesimulated network traffic includes: (i) first simulated network trafficassociated with a first set of virtual machines on the compute node, thefirst set of virtual machines in communication with the firstsoftswitch, the first simulated traffic corresponding to previouslymonitored network traffic obtained during operation of the first set ofvirtual machines; and (ii) second simulated network traffic associatedwith the new virtual machine.

Example 19 includes the subject matter of any one of examples 15 to 18,and further includes deleting the second softswitch and the updated timesensitive networking schedule from the compute node in response to adetermination that the first set of constraints is not met for thesimulated network traffic processed by the second softswitch based onthe updated time sensitive networking schedule.

Example 20 includes the subject matter of any one of examples 15 to 19,wherein the second softswitch is associated with a second configurationspecification, the second configuration specification to correspond tothe first configuration specification when the second softswitch isinitially deployed on the compute node, and in response to thedetermination that the first set of constraints is met for the simulatednetwork traffic, further including adjusting the second configuration ofthe second softswitch to satisfy at least one of a second set ofconstraints to be met for the simulated network traffic processed by thesecond softswitch based on the updated time sensitive networkingschedule.

Example 21 includes the subject matter of example 20, and furtherincludes iteratively adjusting the second configuration of the secondsoftswitch to satisfy other ones of the second set of constraints to bemet for the simulated network traffic until a time limit is reached.

Example 22 is an apparatus including means for replacing a firstsoftswitch implementing a first time sensitive networking schedule on acompute node with a second softswitch implementing a second timesensitive networking schedule different from the first time sensitivenetworking schedule, the means for replacing to: (i) deploy the secondsoftswitch on the compute node based on a first configurationspecification associated with the first softswitch; (ii) configure thesecond softswitch to implement the second time sensitive networkingschedule; and (iii) replace the first softswitch with the secondsoftswitch in response to a determination that a first set ofconstraints is met for simulated network traffic processed by the secondsoftswitch based on the second time sensitive networking schedule. Theapparatus of example 22 also includes means for applying the simulatednetwork traffic to the second softswitch.

Example 23 includes the subject matter of example 22, wherein the firstsoftswitch is to communicate with respective first ports ofcorresponding ones of a first set of virtual machines on the computenode to provide the first set of virtual machines with access to anetwork that implements time sensitive networking, and the means forreplacing is to: (i) connect the second softswitch to a networkinterface of the compute node; (ii) add respective second ports tocorresponding ones of the first set of virtual machines; (iii) bind therespective second ports of the corresponding ones of the first set ofvirtual machines to the second softswitch; (iv) delete the respectivefirst ports of the corresponding ones of the first set of virtualmachines; and (v) delete the first softswitch from the compute node.

Example 24 includes the subject matter of example 22 or example 23,wherein the second time sensitive networking schedule is to supportdeployment of a new virtual machine to the compute node to host aworkload, and the means for replacing is to: (i) connect a port of thenew virtual machine to the second softswitch; (ii) configure theworkload to operate in a test mode; (iii) monitor a metric associatedwith the simulated network traffic processed by the second softswitch;and (iv) configure the workload to operate in an operational mode afterthe determination that the first set of constraints is met for thesimulated network traffic processed by the second softswitch based onthe second time sensitive networking schedule.

Example 25 includes the subject matter of example 24, wherein thesimulated network traffic includes: (i) first simulated network trafficassociated with a first set of virtual machines on the compute node, thefirst set of virtual machines in communication with the firstsoftswitch, the first simulated traffic corresponding to previouslymonitored network traffic obtained during operation of the first set ofvirtual machines; and (ii) second simulated network traffic associatedwith the new virtual machine.

Example 26 includes the subject matter of any one of examples 22 to 25,wherein the means for replacing is to delete the second softswitch andthe second time sensitive networking schedule from the compute node inresponse to a determination that the first set of constraints is not metfor the simulated network traffic processed by the second softswitchbased on the second time sensitive networking schedule.

Example 27 includes the subject matter of any one of examples 22 to 26,wherein the second softswitch is associated with a second configurationspecification, the second configuration specification to correspond tothe first configuration specification when the second softswitch isinitially deployed on the compute node, and in response to thedetermination that the first set of constraints is met for the simulatednetwork traffic, the means for replacing is to adjust the secondconfiguration of the second softswitch to satisfy at least one of asecond set of constraints to be met for the simulated network trafficprocessed by the second softswitch based on the second time sensitivenetworking schedule.

Example 28 includes the subject matter of example 27, wherein the meansfor replacing is to iteratively adjust the second configuration of thesecond softswitch to satisfy other ones of the second set of constraintsto be met for the simulated network traffic until a time limit isreached.

Example 29 is an apparatus to change a time sensitive networkingschedule implemented by a softswitch on a compute node. The apparatus ofexample 29 includes a central user configurator to parse a virtualizedindustrial function descriptor corresponding to a virtualized workloadto determine a set of parameters for an updated time sensitivenetworking schedule to be implemented by the softswitch. The apparatusof example 29 also includes a central network configurator to: (i)determine the updated time sensitive networking schedule based on theset of parameters; and (ii) send the updated time sensitive networkingschedule to the compute node.

Example 30 includes the subject matter of example 29, and furtherincludes an orchestrator to parse the virtualized industrial functiondescriptor to determine a virtual machine configuration specificationfor a virtual machine to deploy on the compute node to host thevirtualized workload, and to send the virtual machine configurationspecification to the compute node to cause the virtual machine to bedeployed on the compute node.

Example 31 includes the subject matter of example 30, wherein theorchestrator is to delete the virtual machine from the compute node inresponse to a message from the compute node indicating a first set ofconstraints is not met by the updated time sensitive networkingschedule.

Example 32 includes the subject matter of any one of examples 29 to 31,wherein the central user configurator is to delete the updated timesensitive networking schedule in response to a message from the computenode indicating a first set of constraints is not met by the updatedtime sensitive networking schedule.

Example 33 includes the subject matter of any one of examples 29 to 32,wherein the central user configurator is to: (i) determine whether thecentral network configurator supports generation of the updated timesensitive networking schedule based on a first one of the set ofparameters; and (ii) discard the first one of the set of parameters whenthe central network configurator does not support generation of theupdated time sensitive networking schedule based on the first one of theset of parameters.

Example 34 includes the subject matter of any one of examples 29 to 32,wherein the central user configurator is to: (i) determine whether thecentral network configurator supports generation of the updated timesensitive networking schedule based on a first one of the set ofparameters; and (ii) replace the first one of the set of parameters witha different parameter when the central network configurator does notsupport generation of the updated time sensitive networking schedulebased on the first one of the set of parameters.

Example 35 is at least one non-transitory computer readable mediumcomprising computer readable instructions which, when executed, cause atleast one processor to at least: (i) parse a virtualized industrialfunction descriptor corresponding to a virtualized workload to determinea set of parameters for a second time sensitive networking schedule tobe implemented by a softswitch on a compute node, the second timesensitive networking schedule different from a first time sensitivenetworking schedule already implemented by the softswitch on the computenode; (ii) determine the second time sensitive networking schedule basedon the set of parameters; and (iii) send the second time sensitivenetworking schedule to the compute node.

Example 36 includes the subject matter of example 35, wherein theinstructions, when executed, cause the at least one processor to: (i)parse the virtualized industrial function descriptor to determine avirtual machine configuration specification for a virtual machine todeploy on the compute node to host the virtualized workload; and (ii)send the virtual machine configuration specification to the compute nodeto cause the virtual machine to be deployed on the compute node.

Example 37 includes the subject matter of example 36, wherein theinstructions, when executed, further cause the at least one processor todelete the virtual machine from the compute node in response to amessage from the compute node indicating a first set of constraints isnot met by the second time sensitive networking schedule.

Example 38 includes the subject matter of example 35 or example 36,wherein the instructions, when executed, cause the at least oneprocessor to delete the second time sensitive networking schedule inresponse to a message from the compute node indicating a first set ofconstraints is not met by the second time sensitive networking schedule.

Example 39 is a method to change a time sensitive networking scheduleimplemented by a softswitch on a compute node. The method of example 39includes parsing a virtualized industrial function descriptorcorresponding to a virtualized workload to determine a set of parametersfor an updated time sensitive networking schedule to be implemented bythe softswitch. The method of example 39 also includes determining theupdated time sensitive networking schedule based on the set ofparameters. The method of example 39 further includes sending theupdated time sensitive networking schedule to the compute node.

Example 40 includes the subject matter of example 39, and furtherincludes (i) parsing the virtualized industrial function descriptor todetermine a virtual machine configuration specification for a virtualmachine to deploy on the compute node to host the virtualized workload;and (ii) sending the virtual machine configuration specification to thecompute node to cause the virtual machine to be deployed on the computenode.

Example 41 includes the subject matter of example 40, and furtherincludes deleting the virtual machine from the compute node in responseto a message from the compute node indicating a first set of constraintsis not met by the updated time sensitive networking schedule.

Example 42 includes the subject matter of example 39 or example 40, andfurther includes deleting the updated time sensitive networking schedulein response to a message from the compute node indicating a first set ofconstraints is not met by the updated time sensitive networkingschedule.

Example 43 is an apparatus including means for parsing a virtualizedindustrial function descriptor corresponding to a virtualized workloadto determine a set of parameters for a second time sensitive networkingschedule to be implemented by a softswitch on a compute node, the secondtime sensitive networking schedule different from a first time sensitivenetworking schedule already implemented by the softswitch on the computenode. The apparatus of example 43 also includes means for determiningthe second time sensitive networking schedule based on the set ofparameters, the means for determining the second time sensitivenetworking schedule to send the second time sensitive networkingschedule to the compute node.

Example 44 includes the subject matter of example 43, and furtherincludes means for determining a virtual machine configurationspecification for a virtual machine to deploy on the compute node tohost the virtualized workload, the means for determining the virtualmachine configuration specification to: (i) parse the virtualizedindustrial function descriptor to determine the virtual machineconfiguration specification; and (ii) send the virtual machineconfiguration specification to the compute node to cause the virtualmachine to be deployed on the compute node.

Example 45 includes the subject matter of example 44, wherein the meansfor determining the virtual machine configuration specification isfurther to delete the virtual machine from the compute node in responseto a message from the compute node indicating a first set of constraintsis not met by the updated time sensitive networking schedule.

Example 46 includes the subject matter of example 43 or example 44,wherein the means for determining the second time sensitive networkingschedule is further to delete the second time sensitive networkingschedule in response to a message from the compute node indicating afirst set of constraints is not met by the second time sensitivenetworking schedule.

Example 47 includes the subject matter of any one of examples 1 to 7,wherein the second softswitch is a duplicate of the first softswitchwhen the second softswitch is initially deployed on the compute node bythe network node configurator.

Example 48 includes the subject matter of any one of examples 8 to 14,wherein the second softswitch is a duplicate of the first softswitchwhen the second softswitch is initially deployed on the compute node.

Example 49 includes the subject matter of any one of examples 15 to 21,wherein the second softswitch is a duplicate of the first softswitchwhen the second softswitch is initially deployed on the compute node.

Example 50 includes the subject matter of any one of examples 22 to 28,wherein the second softswitch is a duplicate of the first softswitchwhen the second softswitch is initially deployed on the compute node.

Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

The following claims are hereby incorporated into this DetailedDescription by this reference, with each claim standing on its own as aseparate embodiment of the present disclosure.

1. (canceled)
 2. An apparatus to change a time sensitive networkingschedule implemented by a softswitch on a compute node, the apparatuscomprising: at least one memory; instructions in the apparatus; andprocessor circuitry to execute the instructions to at least: parse avirtualized industrial function descriptor corresponding to avirtualized workload to determine a set of parameters for an updatedtime sensitive networking schedule to be implemented by the softswitch;determine the updated time sensitive networking schedule based on theset of parameters; and send the updated time sensitive networkingschedule to the compute node.
 3. The apparatus of claim 2, wherein theprocessor circuitry is to: parse the virtualized industrial functiondescriptor to determine a virtual machine configuration specificationfor a virtual machine to deploy on the compute node to host thevirtualized workload; and send the virtual machine configurationspecification to the compute node to cause the virtual machine to bedeployed on the compute node.
 4. The apparatus of claim 3, wherein theprocessor circuitry is to delete the virtual machine from the computenode in response to a message from the compute node indicating a firstset of constraints is not met by the updated time sensitive networkingschedule.
 5. The apparatus of claim 2, wherein the processor circuitryis to delete the updated time sensitive networking schedule in responseto a message from the compute node indicating a first set of constraintsis not met by the updated time sensitive networking schedule.
 6. Atleast one non-transitory computer readable medium comprising computerreadable instructions which, when executed, cause at least one processorto at least: parse a virtualized industrial function descriptorcorresponding to a virtualized workload to determine a set of parametersfor a second time sensitive networking schedule to be implemented by asoftswitch on a compute node, the second time sensitive networkingschedule different from a first time sensitive networking schedulealready implemented by the softswitch on the compute node; determine thesecond time sensitive networking schedule based on the set ofparameters; and send the second time sensitive networking schedule tothe compute node.
 7. The at least one non-transitory computer readablemedium of claim 6, wherein the instructions, when executed, cause the atleast one processor to: parse the virtualized industrial functiondescriptor to determine a virtual machine configuration specificationfor a virtual machine to deploy on the compute node to host thevirtualized workload; and send the virtual machine configurationspecification to the compute node to cause the virtual machine to bedeployed on the compute node.
 8. The at least one non-transitorycomputer readable medium of claim 7, wherein the instructions, whenexecuted, further cause the at least one processor to delete the virtualmachine from the compute node in response to a message from the computenode indicating a first set of constraints is not met by the second timesensitive networking schedule.
 9. The at least one non-transitorycomputer readable medium of claim 6, wherein the instructions, whenexecuted, cause the at least one processor to delete the second timesensitive networking schedule in response to a message from the computenode indicating a first set of constraints is not met by the second timesensitive networking schedule.
 10. A method to change a time sensitivenetworking schedule implemented by a softswitch on a compute node, themethod comprising: parsing a virtualized industrial function descriptorcorresponding to a virtualized workload to determine a set of parametersfor an updated time sensitive networking schedule to be implemented bythe softswitch; determining the updated time sensitive networkingschedule based on the set of parameters; and sending the updated timesensitive networking schedule to the compute node.
 11. The method ofclaim 10, further including: parsing the virtualized industrial functiondescriptor to determine a virtual machine configuration specificationfor a virtual machine to deploy on the compute node to host thevirtualized workload; and sending the virtual machine configurationspecification to the compute node to cause the virtual machine to bedeployed on the compute node.
 12. The method of claim 11, furtherincluding deleting the virtual machine from the compute node in responseto a message from the compute node indicating a first set of constraintsis not met by the updated time sensitive networking schedule.
 13. Themethod of claim 10, further including deleting the updated timesensitive networking schedule in response to a message from the computenode indicating a first set of constraints is not met by the updatedtime sensitive networking schedule.
 14. An apparatus comprising: meansfor parsing a virtualized industrial function descriptor correspondingto a virtualized workload to determine a set of parameters for a secondtime sensitive networking schedule to be implemented by a softswitch ona compute node, the second time sensitive networking schedule differentfrom a first time sensitive networking schedule already implemented bythe softswitch on the compute node; and means for determining the secondtime sensitive networking schedule based on the set of parameters, themeans for determining the second time sensitive networking schedule tosend the second time sensitive networking schedule to the compute node.15. The apparatus of claim 14, further including means for determining avirtual machine configuration specification for a virtual machine todeploy on the compute node to host the virtualized workload, the meansfor determining the virtual machine configuration specification to:parse the virtualized industrial function descriptor to determine thevirtual machine configuration specification; and send the virtualmachine configuration specification to the compute node to cause thevirtual machine to be deployed on the compute node.
 16. The apparatus ofclaim 15, wherein the means for determining the virtual machineconfiguration specification is further to delete the virtual machinefrom the compute node in response to a message from the compute nodeindicating a first set of constraints is not met by the updated timesensitive networking schedule.
 17. The apparatus of claim 16, whereinthe means for determining the second time sensitive networking scheduleis further to delete the second time sensitive networking schedule inresponse to a message from the compute node indicating a first set ofconstraints is not met by the second time sensitive networking schedule.